The 3rd Generation Partnership Project (3GPP) long term evolution (LTE) system, introduced as 3GPP release 8, is an improved universal mobile telecommunication system (UMTS). An LTE system offers high peak data rates, low latency, improved system capacity, and low operating cost resulting from simple network architecture. In the LTE system, an evolved universal terrestrial radio access network (E-UTRAN) includes a plurality of evolved Node-Bs (eNBs) communicating with a plurality of mobile stations, referred as user equipment (UE). 3GPP introduces new features to help LTE system operators further optimize network planning in a cost-effective way. Problem event reporting and MDT are two such features where UEs detect problem events, log measurement and send such information to their serving eNBs. At the same time, MDT has been introduced for the legacy UMTS system, It is expected that problem event reporting may also be introduced in the future.
Current 3GPP standard supports reporting of some problem events, such as Radio Link Failure (RLF) reporting, which helps with mobility robustness optimization, and Random Access Channel (RACH) attempt failure reporting, which helps with RACH optimization. Typical problem events that are relevant to network optimization include RLF, RACH failure, handover failure, call setup failure and other failures that may result from network planning issues. Furthermore, problem events happened in UE idle mode, such as UE entering out-of-service state, or UE having cell reselection failure, etc., are also important information that may help operators understand a possible network-planning problem.
For optimization purposes, it is important to know whether a problem occurred due to network coverage issues or due to Radio Resource Management (RRM) configuration issues. Therefore, a logged problem event report needs to be correlated with a concurrent system state and network configuration. The correlation between the problem event report and the concurrent system and network condition becomes even more important when automatic optimization is used, where the time between observing problems and making correctional configuration changes could be short. Some problem events with high significance, such as RLF, handover failure and initial access failure, are rare in a working network. UEs log these events and are expected to deliver the logged information to the network soon after their occurrences. For example, in 3GPP Release 9, a UE indicate if it has information about RLF failure and RACH report in the Radio Resource Control (RRC) re-establishment procedure. The network must fetch the logged information before UE establishes another connection. In general, the system uses time stamping as a means to correlate observed problems, e.g. problems observed in different network nodes such as eNB and Mobility Management Entity (MME). For the moment the details of post-processing failure event reports from the UE has not been standardized. From current principles it can anyway be assumed that network would use time stamp to correlate a problem event report with a network condition. Time stamping is an important way to correlate a problem event report with the concurrent network condition.
In current systems, there are two main methods to time stamp observations and measurements done by a mobile device. The first method is to add a time stamp to a reported observation by the network. Such method is used for problem events when the problem event report is delivered immediately after the problem event occurs, such as RLF report and RACH report for 3GPP rel-8 and 9 systems. In these cases, a reporting UE does not add time stamps to its problem event report. Instead, the network, upon receiving these reports, adds time stamp to them. This method is similar to immediate MDT defined in the 3GPP standard. The second current art method would be to add a time stamp to a problem event report by the UEs, similar to logged MDT. Furthermore similar to logged MDT, it is assumed that the radio connection layers of a UE do not have access to accurate absolute time. To be able to add a time stamp for logged MDT, a UE receives a reference time from the network when configured for logging. The UE then increases the value of the reference time automatically and adds the resulting time stamp to a problem event report upon detecting a problem event. This method is used for logged MDT in the 3GPP standard. It is not used for problem event reporting because there is no prior configuration for problem event reporting. It is also not suitable to introduce such configuration, because due to the low rate of problem events in normal operation all or almost all UE should all the time be ready to record problem event information, and keeping all UEs configured, including keep UE time up to date would involve significant signaling overhead. Both of the time stamping methods have their limitations and cannot meet the requirement of the evolving LTE systems.
With progress made in the 3GPP release-10 standard, the above traditional time stamping methods do not work efficiently in the evolving LTE systems. In certain scenarios, these methods do not work at all. For example, the above methods have problem working in an environment with inter-technology mobility. 3GPP defines inter-RAT (Radio Access Technology) mobility and inter-Technology mobility. The former refers to mobility between LTE and earlier 3GPP technologies. The latter refers to mobility between 3GPP technologies and non-3GPP technologies. Under LTE standard, UEs can move between different RATs. In network deployments where a first RAT provides spotty coverage and a second RAT provides overall coverage, inter-RAT mobility from the first to the second RAT at failure events would be common. Normally, different RAT has different Operations, Administration and Maintenance (OAM) systems. Therefore, a UE would not report problem event information in a RAT that is different from the one where the problem occurred. In such scenarios, the UE should store the problem event information when connecting to another RAT so that the problem event information can be retrieved by the system in the original RAT where the problem occurred. Such feature, however, requires improved time information to correlate the delayed problem event report with its concurrent network condition.
In addition to problem event reporting, 3GPP also introduces MDT to help with network optimization. MDT feature enables UEs to perform OAM activities, such as neighborhood detection, measurements, logging and recording for OAM purposes, which include RRM and optimization purposes. MDT helps with network optimization traditionally done by costly drive testing. In current systems, MDT has the same time stamping problems like the problem event reporting. Furthermore, since MDT logging is high battery consuming, it poses problems in battery condition handling.
A UE running on limited power source, such as battery, needs to concern battery condition handling when enabling MDT logging. MDT logging can be highly battery consuming. The MDT feature assumes that a UE can be configured for MDT in a certain part of the network that supports MDT, and then performs MDT measurements while in a part of the network that does not support MDT. Because MDT cannot be reconfigured in the part of the network not supporting MDT, the logging duration in a MDT logging configuration could be set long so that a UE can perform MDT measurement and MDT logging even when out of the MDT-supported area. Furthermore, in order to better correlate the MDT measurements with UE location, the network may initiate UE location determination by Global Navigation satellite System (GNSS), which consumes a significant amount of power.
Battery condition has high impact on user perception. Power consumption in active mode is always higher than in idle mode. It is commonly understand that a user would have control over battery usage to keep active session short and close down active applications if he/she would want to conserve battery. Therefore, users should have the control over the MDT application running on its phone to shut down the application as they see the need, just like other application. Thus, in order to support good user perception, the UE need to implement battery handling for MDT logging and measuring that may take place in active or idle mode. It should follow the principle of most application procedures initiated in idle mode with autonomous actions based on the battery condition, rather than being commanded by the network. In current systems, when a 3GPP UE is turned off, it is assumed that the UE loses all stored MDT information. A UE will automatically turn off when it detects critically low battery condition. Therefore, improvement is desired to better handle low battery condition for such high power consuming activities like MDT logging. Furthermore, such battery condition handling needs to have measurable ways so that the condition is testable.